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Generic  Avionics 
Software  Specification 


Abstract:  This  report  informally  specifies  the  general  functions,  data  interactions, 
and  timing  constraints  for  a  hypothetical  avionics  mission  control  computer  (MCC) 
system.  Avionics  functions  and  equipment  are  described  only  to  the  extent 
needed  to  specify  generic  MCC  behavior.  The  specification  was  developed  pri¬ 
marily  to  exemplify  timing  requirements  and  functional  interactions  in  a  heavily 
loaded  real-time  system.  The  devices,  functions,  and  architecture  presented  here 
were  prepared  for  illustrative  purposes  and  are  not  those  of  any  specific  military 
aircraft.  In  particular,  the  quantitative  timing  information  and  discussion  of  func¬ 
tional  interactions  is  hypothetical. 

The  specification  consists  of  an  introductory  description  of  the  environment  in 
which  the  mission  computer  operates  followed  by  a  functional  description  of  the 
requirements  imposed  on  the  mission  computer.  The  functional  description  is 
minimal  and  serves  mainly  to  characterize  computer  workload  and  data  inter¬ 
actions.  An  appendix  contains  a  summary  of  the  timing  requirements  together 
with  an  analysis  of  the  expected  CPU  load  for  a  possible  attack  scenario. 


1.  Introduction 

This  document  presents  an  informal  and  partial  specification  for  a  hypothetical  avionics  mis¬ 
sion  control  computer  (MCC)  system.  Although  the  specification  is  reasonably  represen¬ 
tative  of  the  complexity,  functional  load,  and  data  handling  constraints  typical  of  a  wide 
variety  of  aircraft  platforms,  the  avionics  functions  and  equipment  are  described  only  to  the 
extent  needed  to  illustrate  the  general  nature  of  MCC  functions.  Moreover,  the  quantitative 
and  qualitative  information  given  in  this  report  is  not  identical  to  the  specifications  for  any 
actual  aircraft.  This  information  has  been  created  to  illustrate  certain  real-time  issues  that 
must  be  addressed  in  developing  software  for  certain  kinds  of  real-time  systems. 

This  document  nas  been  produced  for  a  project  whose  goal  is  to  implement  and  compare 
several  competing  Ada  real-time  architectures,  thus  providing  a  basis  for  evaluating  them 
with  respect  to  attributes  such  as: 

•  Meeting  all  application  time  constraints. 

•  Encouraging  correct  software  design  and  implementation. 

•  Facilitating  a  robust  design  in  the  event  of  new  hardware  or  new  functional  re¬ 
quirements. 

•  Meeting  time  constraints  with  and  without  Ada  run-time  scneduling  modifica¬ 
tions. 

The  functional  specification  has  been  structured  to  restrict  a  software  design  as  little  as  pos¬ 
sible.  The  intent  is  to  allow  a  wide  variety  of  possible  implementation  approaches. 
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A.  i  aircraft  with  the  equipment  described  in  this  specification  could  have  several  possible 
missions,  such  as  strike,  escort,  interdiction,  etc.  The  functions  described  here,  however, 
are  confined  to  those  needed  for  a  single  mission,  an  air-to-surface  attack.  Furthermore,  we 
assume  that  the  aircraft  is  configured  only  with  the  specified  weapons  and  sensors,  that  it 
has  arrived  at  the  location  at  which  this  mission  is  to  be  performed,  and  that  it  is  (so  far) 
undamaged.  Thus,  we  do  not  currently  plan  to  use  this  specification  to  investigate  the  ef¬ 
fects  of  major  mode  changes  due  to  damage  or  mission  phase. 

Although  we  identify  a  set  of  devices  available  for  our  hypothetical  aircraft,  we  do  not  at¬ 
tempt  to  specify  each  completely;  in  particular,  we  omit  details  that  are  not  germane  to  the 
mission  defined  above.  For  example,  built-in  test  functionality  is  described  only  with  respect 
to  the  timing  requirements  for  determining  and  reporting  device  failures. 

This  specification  does  not  identify  the  processor  to  be  used,  although  we  do  assume  it  is  a 
general  purpose  processor  having  a  nominal  performance  in  the  vicinity  of  1  million  instruc¬ 
tions  per  second  and  sufficient  memory  to  perform  the  required  functions.  Thus  problems 
associated  with,  for  example,  memory  addressing  and  I/O  limitations  of  existing  avionics 
processors  such  as  the  AN/A YK- 14  or  MIL-STD-1750A,  are  not  considered. 

The  remainder  of  this  specification  consists  of  two  sections:  an  introductory  description  of 
the  environment  in  which  the  mission  computer  operates  followed  by  a  description  of  the 
functions  to  be  performed  by  the  mission  computer  in  that  environment.  Included  in  the 
functional  description  is  the  response  time  or  periodicity  requirement  for  each  device  and 
function  together  with  a  broad  description  of  the  information  that  must  be  handled  for  each 
function.  Appendix  A  contains  a  glossary  of  acronyms.  Appendix  B  contains  a  summary  of 
the  timing  requirements  together  with  an  analysis  of  the  expected  CPU  load  for  a  particular 
attack  scenario. 
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2.  Typical  Avionics  Systems 

This  chapter  provides  an  introductory  discussion  of  MCC  functions  found  in  typical  Navy/ 
Marine  Corps  aircraft.  Typical  MCC  functions  include  navigation,  sensor  control,  weapons 
targeting  and  release,  controls  and  displays  management,  and  fault  isolation  test.  Other 
specialized  avionics  computers  (e.g.,  those  that  handle  radar  signal  processing,  dynamic  air 
data,  inertial  navigation,  threat  warning,  weapons  and  stores  management,  flight  control, 
and  display  processing)  are  mentioned  only  to  provide  a  context  for  the  mission  control  com¬ 
puter  functions. 


2.1.  Avionics  System  Structure 

Combat  aircraft  employ  a  federated,  distributed  computer  network  with  many  specialized 
processors  to  perform  avionics  functions.  These  processors  are  controlled  by  the  MCC  and 
are  interconnected  by  one  or  more  serial  data  buses.  Although  the  MCC  is  typically  a  single 
processor  in  existing  systems,  the  specification  in  Section  3  is  not  intended  to  imply  that  this 
is  a  requirement.  The  data  bus  used  is  designed  to  have  a  unique  bus  controller  which 
determines  tenancy  on  the  bus;  the  MCC  typically  is  the  bus  controller. 

Figure  2-1  is  a  high  level  block  diagram  for  the  avionics  system  of  our  attack  aircraft.  See 
Appendix  A  for  explanations  of  the  acronyms  used.  Only  the  most  important  avionics  com¬ 
ponents  (from  the  point  of  view  of  mission  computer  processing)  are  shown. 


Figure  2-1 :  Avionics  Block  Diagram 
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The  actual  functions  performed  by  the  various  boxes  are  described  in  the  following  sections. 
The  boxes  represent  the  following  equipment: 

•  Display  Processor  (DP),  which  controls  the  following: 

-  Head  Up  Display  (HUD) 

-  Multi-Purpose  Display  (MPD) 

-  Keyset 

Inertial  Navigation  System  (INS) 

•  Air  Data  Computer  (ADC) 

•  Stores  Management  System  (SMS) 

•  Radar 

•  Radar  Altimeter  (RALT) 

•  Radar  Warning  Receiver  (RWR) 

•  Hands-On  Throttle  And  Stick  (HOT AS) 


2.2.  Controls  and  Displays 

Controls  and  displays  include  the  head-up  display  (HUD),  the  multi-purpose  display  (MPD), 
the  aircrew’s  keyset,  and  the  hands-on  throttle  and  stick  (HOTAS)  switches.  These  define 
the  man-machine  interface  between  the  aircrew  and  the  avionics  computers. 

A  modem  combat  aircraft  places  an  enormous  workload  on  an  aircrew,  particularly  during 
the  most  stressful  phases  of  a  mission  such  as  air-to-air  combat  or  attack  on  a  highly 
defended  ground  or  surface  target.  Cockpit  controls  and  displays  are  designed  to  be  mul¬ 
tipurpose,  configurable,  and  easy-to-use.  This  means  that  most  controls  are  software- 
programmable  switches  and  most  displays  are  computer-generated.  Primary  exceptions 
are  HOTAS  controls  (that  must  be  easy  to  reach  during  high-G  maneuvers)  and  backup 
controls  and  displays  for  use  in  the  event  of  computer  failure  (which  we  will  ignore  in  this 
document). 

At  least  two  simultaneous  displays  are  normally  available.  The  HUD  display,  which  is  a 
transparent  display  with  computer-generated  images  superimposed  on  the  out-the-window 
view,  shows  aircraft  flight  data  (airspeed,  pitch  ladder,  heading,  etc.)  plus  weapon  aim  point 
and/or  seeker  position.  The  MPD  display  usually  shows  the  tactical  situation,  including 
threat  data,  superimposed  on  a  digital  moving  map.  The  MPD  can  also,  by  aircrew  selec¬ 
tion,  show  a  display  of  stores  (expendables)  remaining,  sensor  (radar)  visual  display  infor¬ 
mation,  status  and  warning  information,  or  a  duplicate  of  the  HUD  display. 

In  some  current  aircraft  (e.g.,  the  F/A-18)  display  management  is  done  in  a  mission  com¬ 
puter,  but  the  trend  is  toward  use  of  special-purpose  display  processors  that  control  the 
HUD,  MPD,  and  aircrew’s  keyset. 

As  shown  in  Figure  2-1,  the  HOTAS  is  connected  both  to  the  Display  Processor  and  to  the 
Stores  Management  System. 
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2.3.  Sensors 


Attack  aircraft  typically  carry  three  types  of  sensors:  navigation  sensors,  threat  warning  sen¬ 
sors,  and  targeting  sensors. 

Navigation  sensors  include: 

•  Air  Data  Computer  (ADC):  provides  barometric  altimeter  plus  dynamic  and 
static  pressure  data. 

•  Inertial  Navigation  System  (INS):  provides  aircraft  position  and  velocity  plus  at¬ 
titude  and  heading  reference  data. 

•  Radar  Altimeter  (RALT):  provides  measured  height  above  the  ground. 

The  Radar  Warning  Receiver  (RWR)  is  a  threat  warning  sensor  that  warns  the  aircrew  of 
hostile  radar  energy  being  beamed  at  the  aircraft,  such  as  from  a  fire  control  radar  or  a 
radar-homing  missile. 

Targeting  sensors,  such  as  radar,  provide  range  and  angle  data  (including  rates)  of  suf¬ 
ficient  accuracy  to  track  moving  targets.  Targeting  sensors  may  be  active  (emitting  energy, 
such  as  the  radar)  or  passive  (sensing  the  energy  emitted  from  the  target,  such  as  a  target¬ 
ing  TV  video  tracker).  In  the  future,  increased  reliance  on  passive  targeting  is  likely  because 
of  the  reduced  chances  for  enemy  detection  and  counter-measures. 


2.4.  Stores 

Fighter/attack  aircraft  can  carry  a  number  of  items  fastened  to  racks  underneath  the  aircraft. 
These  items  are  called  “stores"  and  include  weapons  (bombs,  rockets,  missiles),  extra  fuel 
tanks,  extra  sensor  pods,  or  decoys  (e.g.,  chaff  to  fool  radar-guided  missiles  and  flares  to 
fool  infra-red  guided  missiles).  The  Stores  Management  System  (SMS)  manages  the  me¬ 
chanical  and  electrical  connections  to  weapons  and  senses  their  status  under  control  of  the 
MCC;  thus  all  weapons  are  readied  via  the  SMS. 

Weapons  carried  may  include  rockets,  bombs  (both  ballistic  and  radar,  infra-red,  or  TV 
guided),  and  missiles  (which  are  typically  "fire  and  forget”  self-guided  using  TV  video,  laser, 
imaging  infra-red,  or  radar  seekers).  Most  aircraft  also  have  internal  fuselage-mounted 
guns. 

Weapon  release  modes  include  automatic  (AUTO)  and  continuously  computed  impact  point 
(CCIP)  plus  special  modes  for  guided  weapons.  In  AUTO  mode,  the  MCC  controls  weapon 
release  based  on  computed  impact  point,  current  target  position,  and  predicted  aircraft  posi¬ 
tion  at  release.  In  CCIP  mode,  the  MCC  computes  a  predicted  impact  point  which  is  dis¬ 
played  on  the  HUD,  and  the  aircrew  controls  weapon  release  with  the  bomb  button  on  the 
HOTAS. 
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Air-to-air  weapons  are  carried  only  for  self-defense  and  typically  consist  of  guns  and  short 
range  air-to-air  heat  seeking  missiles.  For  the  purpose  of  this  specification  (which  describes 
only  an  air-to-ground  attack),  we  restrict  our  weapons  to  six  bombs. 


2,5.  Device  Interface  and  Timing  to  the  MCC 

Communication  to  ail  of  these  devices  is  handled  by  a  standard  military  data  bus.  This  bus 
is  a  one  megabyte  per  second  serial  network  that  contains  a  single  bus  controller  (usually 
the  MCC)  that  periodically  polls  each  device  (called  remote  terminals)  at  a  rate  sufficient  to 
limit  the  latency  of  information  communicated  to  and  from  the  device.  In  no  case  does  a 
device  have  the  ability  to  initiate  an  interrupt  to  the  MCC;  all  communication  takes  place  in 
immediate  response  to  bus  controller  (MCC)  polling. 


2.6.  Interrupts 

In  many  existing  avionics  systems,  designers  take  great  pains  to  avoid  external  interrupts  to 
the  MCC  (the  use  of  a  communications  bus  as  described  in  the  previous  section  eliminates 
the  need  for  most,  if  not  all,  interrupts).  For  other  avionics  systems,  interrupts  provide  a 
primary  mechanism  to  allow  for  asynchronous  events  to  be  provided  to  the  MCC;  devices 
with  a  need  to  ensure  an  immediate  MCC  response  can  generate  an  interrupt  independently 
of  the  data  bus.  In  such  systems,  however,  care  must  be  taken  by  the  designer  to  ensure 
that  the  MCC  is  not  given  unnecessary  interrupts  that  would  interfere  with  the  system’s  abil¬ 
ity  to  respond  to  externally  defined  timing  requirements. 

Although  external  interrupts  to  the  MCC  are  frequently  not  used,  several  types  of  internally 
generated  interrupts  may  disrupt  MCC  processing.  Many  internal  interrupts  represent  error 
conditions,  such  as  MCC  power  loss  or  avionics  serial  data  bus  failure.  Two  types  of  inter¬ 
nally  generated  interrupts  are  part  of  normal  MCC  processing: 

1 .  Expiration  of  timing  delays  for  scheduling  both  periodic  and  aperiodic  process¬ 
ing. 

2.  Input/output  completion  (IOC)  interrupts  from  the  bus  controller  hardware. 

Figure  2-2  shows  clock  and  bus  controller  interrupts  to  the  MCC  central  processor. 


clock 

interrupt 

CPU 

10  request 

IOP 

mm 

Figure  2-2;  Clock  and  Bus  Controller  Interrupts 
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The  MCC  contains  one  or  more  hardware  clocks  to  handle  scheduling  of  periodic  and 
aperiodic  computations.  Typically,  these  are  count-down  clocks.  The  MCC  loads  a  time 
delay  into  the  clock;  the  clock  then  counts  down  to  zero  and  generates  a  clock  expiration 
interrupt  to  the  MCC  main  processor. 

The  MCC  frequently  contains  a  separate  input/output  processor  (IOP)  to  handle  the  commu¬ 
nications  protocol  on  the  avionics  serial  data  bus.  Messages  (either  outgoing  data  or  re¬ 
quests  for  incoming  data)  to  other  avionics  boxes  are  scheduled  by  the  MCC  software  for 
processing  on  the  IOP.  When  IOP  processing  is  completed,  the  IOP  generates  an 
input/output  completion  interrupt  to  the  MCC  main  processor. 


2.7.  Timing  and  Deadlines 

The  majority  of  avionics  processing  time  is  spent  performing  periodic  processing;  even 
aperiodic  tasks  often  are  done  by  servicing  them  periodically.  Thus,  the  definition  of  period 
requirements  for  each  function  is  critical  to  successful  implementation.  Processing  a  func¬ 
tion  at  too  high  a  rate  will  result  in  unnecessary  processor  utilization  and  can  lead  to  proces¬ 
sor  overload.  However,  processing  a  function  at  too  low  a  rate  will  result  in  not  meeting 
significant  mission  requirements  (e.g.,  navigation  accuracy,  human  perception  limits, 
weapon  delivery  accuracy,  etc.). 

Requirements  for  how  frequently  MCC  functions  need  to  be  performed  come  from  three 
sources: 

1 .  Hardware  requirements:  for  example,  sensor  control  computations  usually 
must  be  done  at  a  rate  of  20-1 000  Hz  to  keep  up  with  the  hardware.  Gener¬ 
ally,  sensor  computations  are  done  in  separate  sensor  processors  rather  than 
in  the  MCC  described  here. 

2.  Algorithmic  requirements:  for  example,  weapon  delivery  computations  typically 
need  to  be  done  at  a  rate  of  20-40  Hz  in  order  to  maintain  numerical  stability. 

This  translates  directly  to  the  accuracy  with  which  the  target  may  be  attacked. 

3.  Human  factors  requirements:  for  example,  moving  symbols  on  displays  need 
to  be  updated  at  a  rate  of  10-25  Hz  to  avoid  the  appearance  of  jerky  screen 
movements.  This  range  of  update  rate  reflects  differences  in  the  screen  and 
lighting  characteristics  of  different  hardware;  for  example,  the  HUD  typically 
requires  a  higher  update  rate  than  the  MPD.  Response  to  aircrew  keyset  in¬ 
puts  should  occur  within  200  to  500  ms.  to  convince  the  aircrew  that  the  sys¬ 
tem  is  still  responding. 


2.8.  Modes  of  Processing 

MCC  processing  is  often  organized  into  modes,  such  as  navigation,  air-to-ground,  and  air- 
to-air.  The  information  content  of  displays  differs  depending  on  the  current  processing 
mode.  Some  functions  may  not  be  available  in  some  modes.  For  example,  release  of 
bombs  usually  can  be  done  only  in  air-to-ground  mode.  Change  of  mode  typically  changes 
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the  period  requirements  of  some  of  the  computations.  This  specification  does  not,  however, 
address  mode  change  requirements. 


* 
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3.  MCC  Functional  Specifications 

MCC  primary  functions  can  be  summarized  as  follows: 

•  Navigation:  compute  current  aircraft  flight  data  based  on  inputs  from  the  ADC, 

INS,  and  RALT.  Provide  steering  cues  to  aircrew.  Allow  aircrew  to  update  air¬ 
craft  position. 

•  Radar  Control:  control  radar  mode  of  operation  including  contact  management. 

•  RWR  Control:  “set  up”  sectors  and  frequencies  for  RWR  operation. 

•  Threat  Response:  warn  aircrew  of  threats  using  the  MPD  tactical  display.  Trig¬ 
ger  automatic  chaff  dispensation,  if  selected. 

•  Targeting:  designate  and  track  the  target  of  attack. 

•  Weapons  Control:  select,  aim,  and  release  weapons. 

•  Controls  and  Displays:  handle  aircrew  inputs  and  prepare  various  data  for  dis¬ 
play  on  the  HUD  and  MPD. 

•  Built-in  Test:  monitor  the  status  of  the  avionic  system  and  warn  aircrew  of  any 
problems  or  failures. 

This  section  specifies  the  functions  to  be  performed  by  the  MCC  in  concert  with  other  air¬ 
craft  devices.  For  each  function,  we  provide  a  brief  description,  a  list  of  inputs  and  outputs, 
and  timing  and  sequencing  information. 


3.1.  Aircraft  Flight  Data 

Inputs  are  processed  from  the  ADC,  INS,  and  RALT  to  determine  the  best  available  es¬ 
timates  of  aircraft  position,  velocity,  attitude,  motion  through  airmass,  etc.  Outputs  from  this 
function  are  used  for  steering,  target  designation  and  tracking,  weapon  aiming,  and  display 
to  the  aircrew. 

Timing 

Aircraft  flight  data  must  be  processed  every  55  ms.  in  order  to  maintain  aircraft 
parameters  within  tolerances.  The  processing  takes  8  ms.  to  complete. 

Inputs 

ADC.Angle_of_Attack 
ADC.Mach_Number 
ADC.Barometric_A!titude 
ADC.Magnetic_Heading 
ADC.T  rue_Airspeed 
INS.Body_Rates  (roll,  pitch,  yaw) 

I  NS.  Acceleration  (lateral,  longitudinal,  normal) 

INS.Present_Position  (latitude,  longitude) 

INS.True_Heading 

INS. Velocity  (north,  east,  vertical) 

RALT.Radar_Altitude 
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Outputs 

INS.Reference_Velocity  (north,  east,  vertical) 
NAV.Airspeed 

NAV.Rate_of_Change_Airspeed 
NAV.Position  (latitude,  longitude,  altitude) 
NAV.Angle_of_Attack 
NAV.Attitude  (roll,  pitch,  yaw) 

NAV.Body_Rates  (roll,  pitch,  yaw) 

NAV.FIight_Path_Angle 

NAV.Ground_Speed 

NAV.Ground_T  rack_Angle 

NAV.Magnetic_Variation 

NAV.AItitude 

NAV.Velocity  (north,  east,  vertical) 
NAV.Acceleration  (lateral,  longitudinal,  normal) 
NAV.Wind  (direction,  magnitude) 

N  AV.  Body_to_Earth_T  ransf  orm 
NAV.Body_to_Horizon_Transform 
NAV.Radar_to_Body_T  ransf  orm 
N  AV.  Radar_to_Earth_T  ransf  orm 


3.2.  Steering 

Compute  the  steering  cues  for  display  on  the  HUD  and  MPD  based  either  on  waypoint 
steering  or  target  attack  steering.  The  MCC  can  hold  up  to  15  aircrew-entered  waypoints 
(latitude,  longitude,  altitude)  which  may  be  used  as  steer-to  points  and  as  target  designation 
points.  The  aircrew  may  also  associate  an  offset  (range,  bearing)  from  the  currently  se¬ 
lected  waypoint  which  is  taken  into  account.  Prior  to  target  designation,  steering  cues  are 
provided  based  on  the  currently  selected  waypoint  (if  any).  After  target  designation,  steering 
cues  are  provided  based  on  target  location  relative  to  aircraft  position. 

Timing 

Steering  cues  must  be  updated  every  80  ms.  This  rate  is  dictated  by  human  fac¬ 
tors  considerations  for  operator  cueing  and  for  aircrew  response  time  in  steering 
the  aircraft  on  the  correct  flight  path.  This  update  takes  6  ms.  to  complete. 

Inputs 

NAV.Position  (latitude,  longitude,  altitude) 

NAV.Velocity  (north,  east,  vertical) 

MPD.Waypoint_Counter 

Keyset. Waypoint_Table  (latitude,  longitude,  altitude) 

Keyset.Offset  (range,  bearing) 

Keyset.  Waypoint_Steering_Selected 
AG.Target_Location  (range,  azimuth,  elevation) 
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Outputs 

NAV.Cteer_to_Point  (range,  bearing,  time_to_go) 


3.3.  Radar  Control 

The  radar  operates  in  one  of  three  modes:  ground  map,  ground  search,  or  single-target 
track.  Ground  map  mode  is  used  to  display  a  radar  view  of  terrain  on  the  MPD  radar  dis¬ 
play.  Typically,  however,  this  mode  would  be  used  only  for  terrain  avoidance  enroute  to  the 
target  rather  than  during  an  attack  phase.  Ground  search  mode  is  used  to  detect  and  iden¬ 
tify  possible  ground  targets  and/or  threats  (e.g.,  surface-to-air  missile  sites).  In  ground 
search  mode,  the  radar  reports  contact  range  and  bearing  for  up  to  10  contacts.  The 
aircrew  (via  the  MPD)  may  select  any  one  of  these  contacts  for  the  radar  to  track.  The  MCC 
commands  the  radar  into  single-target  track  mode  and  the  radar  provides  range,  range  rate, 
line-of-sight  (LOS)  angles  (azimuth  and  elevation),  and  LOS  angle  rates  to  the  target. 

Timing 

Contact  range  and  bearing  must  be  updated  every  80  ms.;  target  tracking  data 
must  be  updated  every  40  ms.  This  will  allow  position  calculations  accurate 
enough  for  the  weapon  release  algorithms.  Both  of  these  updates  take  2  ms. 
each  to  complete.  Response  to  the  aircrew  input  to  begin  tracking  must  occur 
within  200  ms.  of  initiation  and  requires  2  ms.  to  complete. 

Inputs 

Radar.  Mode 

Radar.Contact_Table  (range,  bearing) 

Radar.Target_Position  (range,  azimuth,  elevation) 

MPD.Contact_Number_to_T  rack 

Outputs 

Radar.  Mode 

Radar.Contact_Number_to_T  rack 
Radar.Status 


3.4.  Target  Designation 

The  aircrew  may  designate  a  target  for  air-to-ground  attack  in  one  of  two  ways:  by  radar  or 
by  HUD  designate.  Only  one  target  may  be  designated  at  a  time.  To  designate  a  target  by 
radar,  the  radar  must  already  be  tracking  a  target.  The  radar  target  is  identified  as  the 
ground  attack  target  by  a  member  of  the  aircrew  pushing  the  designate  switch  or,  the 
HOTAS.  To  perform  a  HUD  designation,  the  aircrew  must  first  position  the  HUD  reticle  (on 
the  HUD)  using  the  target  designator  controller  (TDC)  switch  on  the  HOTAS  (the  TDC 
switch  is  similar  to  a  joystick).  Once  the  HUD  reticle  is  properly  positioned,  the  aircrew 
pushes  down  on  the  TDC  switch  to  designate  a  target.  The  MCC  must  transform  the  HUD 
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reticle  position  from  HUD  coordinates  to  obtain  range,  azimuth,  and  elevation  to  target.  Mo 
matter  how  the  target  was  designated,  the  HUD  reticle  changes  shape  to  indicate  that  a 
target  is  designated.  A  designated  target  may  be  undesignated  by  pushing  the  undesignate 
switch  on  the  HOTAS. 

Timing 

Capture  of  target  position  relative  to  the  aircraft  must  occur  within  40  ms.  of  target 
designation  in  order  to  provide  target  position  accuracy  sufficient  for  weapon 
employment  and  delivery  processing.  The  capture  of  the  target  position  takes  1 
ms.  to  complete.  Confirmation  of  target  designation  must  occur  within  200  ms.  of 
initiation  and  requires  1  ms.  to  complete. 

Inputs 

NAV.Aircraft_Position  (latitude,  longitude,  altitude) 

HOTAS.  HU  D_Designation_Selected 
HUD.Reticle_Position  (azimuth,  elevation) 
hOTaS.  Hadar_Target_Designation_Selected 
Radar.Target_Position  (range,  azimuth,  elevation) 

HOTAS.Undesignate_Selected 

Outputs 

AG.Target_Location  (range,  azimuth,  elevation) 

AG.Target_Location  (north,  east,  down) 

HUD.Target_Reticle  (shape) 

HUD.Reticle_Position  (azimuth,  elevation) 

AG.Radar_Target_Designation_Selected 

AG.HUD_Target_Designation_Selected 


3.5.  Target  Tracking 

Target  tracking  computations  depend  on  how  the  target  was  designated.  For  a  radar- 
designated  target,  the  radar  continues  to  track  the  target  and  report  target  location  and  mo¬ 
tion  with  respect  to  the  aircraft  (targets  not  tracked  by  radar  are  assumed  to  be  fixed  on  the 
earth’s  surface.)  In  any  case,  the  current  location  of  the  target  with  respect  to  the  aircraft  is 
displayed  on  the  HUD  using  the  modified  HUD  reticle.  For  HUD  designations,  the  aircrew 
may  “sweeten"  (i.e.,  improve)  the  target  by  using  the  TDC  switch  to  move  the  HUD  reticle. 
This  causes  the  MCC  to  recompute  the  target’s  location  with  respect  to  the  aircraft  while 
continuing  to  track  it. 
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Timing 

Target  position  must  be  computed  and/or  obtained  from  the  radar  and  displayed 
on  the  HUD  and  MPD  tactical  display  every  40  ms.  to  maintain  a  real-time  appear¬ 
ance  to  the  aircrew  and  to  avoid  aircrew  oversteering.  The  computation  takes  4 
ms.  to  complete.  Sweetening  of  target  tracking  must  occur  within  40  ms.  of  initi¬ 
ation  and  requires  2  ms.  to  complete. 

Inputs 

NAV.Aircraft_Position  (latitude,  longitude,  altitude) 

AG.Target_Location  (north,  east,  down) 

AG.HUD_Target_Designation_Selected 
HOTAS.TDC_HUD_Reticle_Delta  (azimuth,  elevation) 
AG.Radar_Target_Designation_Selected 
Radar.Target_Position  (range,  azimuth,  elevation) 

Outputs 

AG.Target_Location  (range,  azimuth,  elevation) 

AG.Target_Location  (north,  east,  down) 

HUD.Target_Reticie  (shape) 

HUD.Reticle_Position  (azimuth,  elevation) 


3.6.  Weapon  Selection 

Weapon  selection  includes  selecting  the  type  of  weapon,  the  number  to  drop,  and  the  de¬ 
sired  spacing  on  the  ground.  This  is  done  by  the  aircrew  using  the  MPD  stores  display  and 
Keyset  switches.  Depending  on  the  type  of  weapon  selected,  a  default  delivery  mode  is 
defined  and  displayed.  At  any  time  prior  to  weapon  release,  the  aircrew  may  push  the 
AUTO/CCIP  toggle  switch  on  the  Keyset,  causing  the  delivery  mode  to  change  from  AUTO 
to  CCIP  or  from  CCIP  to  AUTO.  Weapon-ready  determination  is  also  assumed  to  be  part  of 
this  function. 

Timing 

Response  to  aircrew  inputs  must  occur  within  200  ms.  Response  to  the 
AUTO/CCIP  toggle  must  occur  within  200  ms.  of  initiation  and  requires  1  ms.  to 
complete.  These  response  times  are  necessary  to  provide  the  aircrew  with  an 
appearance  of  instantaneous  response.  Weapon  selection  involves  approximately 
20  button  depression  invocations;  each  invocation  takes  1  ms.  to  process.  An  ad¬ 
ditional  2  ms.  is  required  for  formatting  the  weapon  selection  response  after  all 
necessary  information  has  been  entered  by  the  aircrew  and  must  be  completed 
within  400  ms. 
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Inputs 

MPD.Weapon_Select_Request 
Keyset.Quantity_Select_Request 
Keyset.  lnterval_Select_Request 
AG.Delivery_Mode_Selected 
Keyset.  AU  T  0_CC  I  P_T  ogg  le 

Outputs 

MPD.Weapon_Selected 

MPD.Quantity_Selected 

MPD.Interval_Selected 

MPD.Delivery_Mode_Selected 

HUD.Delivery_Mode_Selected 

SMS.Weapon_Selected 

SMS.Quantity_Selected 

SMS.Interval_Selected 

AG.Delivery_Mode_Selected 


3.7.  Weapon  Trajectory  (Ballistics) 

For  ballistic  (unguided)  weapons,  the  MCC  solves  the  ballistic  trajectory  equations  of  mo¬ 
tion.  This  is  done  initially  to  determine  weapon  time  of  fall  when  the  estimated  time-to-go  to 
release  (based  on  aircraft  ground  speed  and  target  ground  range)  is  less  than  one  minute. 
Initialization  must  be  repeated  if  a  new  target  is  designated.  Once  initialized,  the  weapon 
trajectory  must  be  computed  at  least  every  1 00  ms.  Outputs  include  time-to-go  to  release, 
weapon  time  of  fall,  down  range  error,  and  cross  range  error.  When  time-to-go  to  release 
falls  below  800  ms.  and  AUTO  delivery  mode  is  selected,  weapon  release  is  scheduled. 
Thereafter,  whenever  time-to-go  to  release  is  recomputed,  weapon  release  is  rescheduled. 

Timing 

Beginning  one  minute  before  estimated  time-to-go  to  release,  the  weapon  trajec¬ 
tory  must  be  computed  every  1 00  ms.  and  takes  7  ms.  to  complete.  Reinitializa¬ 
tion  of  the  ballistic  trajectory  must  occur  within  400  ms.  of  initiation  and  requires  6 
ms.  to  complete.  AUTO  weapon  release  must  be  scheduled  when  time-to-go  to 
release  is  less  than  800  ms.  These  timing  requirements  are  necessary  to  achieve 
accurate  weapon  aiming. 
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Inputs 

NAV.Aircraft_Position  (latitude,  longitude,  altitude) 
NAV.Barometric_Altitude 

NAV.Aircraft_Velocity  (lateral,  longitudinal,  normal) 

NAV.Mach_Number 

NAV.Wind  (direction,  magnitude) 

N  A  V.  Ang  le_of_Attack 
N A V. Attitude  (roll,  pitch,  yaw) 

NAV.Body_Rates  (roll,  pitch,  yaw) 
AG.Target_Location  (north,  east,  down) 
MPD.Weapon_Selected 
AG.Delivery_Mode_Selected 
SMS.Ballistic_Coefficients 

Outputs 

AG.Time_to_Go_to_Release 

AG.Weapon_Time_of_Fall 

AG.  Weapon_Down_Range_T  ravel 

AG.Weapon_Cross_Range_T  ravel 

AG.Weapon_Down_Range_Error 

AG.Weapon_Cross_Range_Error 


3.8.  Weapon  Release 

The  behavior  of  this  function  depends  on  the  delivery  mode.  In  CCIP  mode,  a  weapon 
release  signal  must  be  sent  from  the  MCC  to  the  SMS  as  soon  as  the  aircrew  pushes  the 
“bomb  button”  on  the  HOTAS.  In  AUTO  mode,  a  weapon  release  signal  must  be  sent  to  the 
SMS  as  soon  as  the  scheduled  weapon  release  time  is  reached,  but  only  if  a  member  of  the 
aircrew  is  pushing  the  "bomb  button."  For  multiple  weapon  releases,  the  MCC  computes 
the  time  interval  between  releases  and  sends  a  release  signal  to  the  SMS  for  each  release. 
This  occurs  for  both  AUTO  and  CCIP  delivery  mode. 

Timing 

A  weapon  release  signal  must  be  sent  to  the  SMS  within  5  ms.  of  the  desired 
release  time  in  order  to  ensure  the  impact  point  on  the  designated  target  and  to 
maintain  consistency  with  the  weapon  trajectory  calculation  and  the  weapon 
release  point  calculation.  Intervals  between  releases  for  multiple  weapon  drops 
will  vary  from  10  to  200  ms.  and  take  1  ms.  to  complete  per  invocation,  with  a 
maximum  of  up  to  6  invocations  (maximum  of  6  bombs  aboard  the  aircraft). 
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Inputs 

AG.Time_to_Go_to_Release 

AG.Weapon_Release_lnterval 

AG.Delivery_Mode_Selected 

SMS.Bomb_Button_Depressed 

Outputs 

SMS.Release_Signal 


3.9.  HUD  Display 

The  display  functions  send  an  legends,  labels,  symbology,  and  numeric  values  for  display  on 
the  HUD.  (Normally,  the  aircrew  can  declutter  the  HUD  by  removing  pre-specified  parts  of 
the  display,  but  we  ignore  this  here).  This  function  also  updates  the  HUD  reticle  position 
when  an  air-to-ground  target  is  designated,  and  updates  the  CCIP  symbology  on  the  HUD 
when  selected. 

Timing 

Moving  symbols  and  numeric  values  must  be  updated  at  least  every  52  ms.  to 
avoid  jerkiness  in  the  display.  Display  update  will  take  6  ms.  to  complete. 

Inputs 

NAV.Airspeed 

NAV.Position  (latitude,  longitude,  altitude) 

NAV.Angle_of_Attack 
NAV. Attitude  (roll,  pitch,  yaw) 

NAV.Body_Rates  (roll,  pitch,  yaw) 

NAV.Barometric_Altitude 
NAV.Velocity  (north,  east,  vertical) 

NAV.Steer_to_Point  (range,  bearing,  time_to_go) 

HUD.Target_Reticle  (shape) 

HUD.Reticle_Position  (azimuth,  elevation) 

AG.Time_to_Go_to_Release 
AG.Delivery_Mode_Selected 
AG.  Weapon_Down_Range_T  ravel 
AG.Weapon_Cross_Range_Travel 
Outputs 

D  P .  H  U  D_N  A  V_Data_Messag  e 
D  P .  H  U  D_Pitch_Ladder_Message 
DP.HUD_Velocity_Vector_Message 
DP.HUD_Steering_Cue_Message  (if  waypoint  or  target) 

DP.HUD_Retic!e_Message 

DP.HUD_Weapon_Release_Message  (if  weapon  selected  and  target  designated) 
DP.HUD_CCIP_Display_Message  (if  CCIP  selected) 


16 


CMU/SEI-90-TR-8 


3.10.  MPD  HUD  Display 

This  duplicate  of  the  HUD  display  is  used  as  a  backup  in  case  of  HUD  hardware  failure. 
The  HUD  reticle  on  the  MPD  cannot  be  used  for  HUD  designation  of  a  target,  but  does 
represent  the  out-the-window  position  of  the  target  if  a  target  is  designated  via  radar. 
Timing,  inputs,  and  outputs  are  the  same  as  for  the  HUD. 


3.11.  MPD  Tactical  Display 

The  MPD  tactical  display  shows  a  “bird’s  eye"  view  of  the  tactical  situation.  The  aircraft  is 
fixed  at  the  center.  Radar  contacts  and  the  target  are  plotted  by  range  and  bearing.  RWR 
threats  are  shown  by  bearing  only.  The  scale  of  the  display  is  variable  from  1  to  100  nauti¬ 
cal  miles. 

Around  the  edge  of  the  MPD  display  are  25  buttons  that  are  software  programmable.  These 
are  used  to  select  display  options,  to  select  waypoints,  to  select  radar  contacts,  to  designate 
the  selected  waypoint  or  radar  contact,  to  select  weapons,  and  to  select  another  MPD  dis¬ 
play  mode. 

Timing 

Moving  symbology  and  numeric  values  must  be  updated  at  least  every  52  ms.  to 
avoid  jitter  in  the  display  appearance.  This  update  takes  8  ms.  to  complete.  Re¬ 
sponse  to  aircrew  switch  selections  (except  to  change  MPD  display  mode)  take  1 
ms.  to  process  and  must  occur  within  200  ms.  Change  of  MPD  display  mode, 
when  selected,  must  occur  within  200  ms.  and  requires  1  ms.  to  complete.  These 
response  times  are  to  meet  human  response  requirements. 

Inputs 

MPD.Tactical_Display_Scale_Selected 
Radar. Contact_Table  (range,  bearing) 

RWR.Threat_Table  (bearing,  frequency) 

NAV.Position  (latitude,  longitude,  altitude) 

NAV.Magnetic_Variation 

NAV.Steer_to_Point  (range,  bearing,  time_to_go) 

Raaar.Target_Position  (range,  azimuth,  elevation) 

AG.Target_Location  (range,  azimuth,  elevation) 

Outputs 

DP.MPD_Tactical_Radar_Contacts_Message 

DP.MPD_Tactical_Radar_Target_Message 

DP.MPD_Tactical_Threats_Display_Message 

DP.MPD_Tactical_Compass_Rose_Message 

DP.MPD_AG_Target_Message 


CMU/SEI-90-TR-8 


17 


3.12.  MPD  Stores  Display 

The  MPD  stores  display  shows  a  wing  platform  and  all  the  stores  hung  on  the  aircraft,  as 
well  as  rounds  remaining  for  fuselage  guns.  MPD  buttons  are  used  to  select  a  type  of 
weapon.  The  SMS  selects  the  particular  wing  station(s)  from  which  to  release  stores  in 
order  to  keep  the  aircraft  balanced.  The  release  sequence  is  also  shown  on  the  MPD  stores 
display.  While  the  MPD  stores  display  is  selected,  the  aircrew  may  enter  weapon  quantity 
and  release  interval  via  the  Keyset. 

Timing 

Timing  regarding  the  stores  display  is  specified  in  Section  3.6.  Timing  regarding 
selection  of  the  display  mode  is  specified  in  Section  3.1 1 . 

Responses  to  aircrew  inputs  {including  selection  of  the  MPD  stores  display)  must 
occur  within  200  ms.  to  meet  human  factors  requirements. 

Inputs 

Numerous 

Outputs 

DP.MPD_Stores_Remaining_Message 


3.13.  MPD  Status  Display 

The  MPD  status  display  shows  the  status  of  all  aircraft  avionics  devices.  Results  from  built- 
in  test  (BIT),  covered  in  Section  3.17,  are  part  of  the  MPD  status  display.  As  described  in 
Section  3.17,  if  BIT  detects  equipment  failure  while  the  MPD  status  display  is  not  selected,  a 
warning  legend  is  flashed  on  both  the  HUD  and  the  MPD  for  2  seconds.  If  BIT  failure  is 
detected  while  the  MPD  status  display  is  selected,  a  warning  legend  is  still  flashed  on  the 
HUD,  but  not  on  the  MPD;  the  status  line  for  the  failed  equipment  flashes  in  reverse  video. 

Timing 

BIT  status  display  updates  take  2  ms.  to  process.  (This  is  in  addition  to  the  5  ms. 
to  perform  the  BIT  calculations  as  specified  in  Section  3.17.)  For  normal  BIT,  the 
status  display  must  be  updated  at  least  every  second.  For  BIT  failure  warnings, 
the  reversed  video  status  must  be  displayed  within  200  ms.;  selection  of  reversed 
video  display  mode  is  assumed  to  take  no  additional  processing  time. 
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Inputs 

MCC.Status 

ADC.Status 

INS.Status 

SMS.Status 

Radar.Status 

RWR.Status 

RALT.Status 

Outputs 

DP.MPD_Periodic_BIT_Message 


3.14.  Keyset  and  HOTAS 

Aircrew  inputs  are  provided  by  both  the  Keyset  and  the  HOTAS.  Of  the  various  buttons  and 
switches  on  the  HOTAS,  three  are  considered  in  this  specification: 

•  Bomb  button:  the  aircrew  pushes  this  button  to  release  the  selected  weapon 
(see  Section  3.8). 

•  Target  Designator  Controller  (TDC):  the  TDC  or  slew  control  is  used  to  move 
the  target  designator  (TD)  symbol  around  on  the  HUD  and  to  designate  a  target 
as  described  in  Section  3.5. 

•  Undesignate  button:  the  aircrew  pushes  this  button  to  cancel  a  target  desig¬ 
nation. 

The  Keyset  consists  of  two  components:  the  keypad  for  entering  position  updates,  weapon 
quantity  and  interval,  and  other  numeric  data,  and  the  options-display,  which  consists  of  but¬ 
tons  with  software-programmed  labels.  The  Keyset  is  used  as  a  aircrew  input  device  for 
many  functions,  including: 

•  Waypoint/offset  entiy  (not  a  part  of  this  specification) 

•  Weapon  programming 

•  Delivery- mode  toggle 

•  Radar  Warning  Receiver  programming 

Timing 

To  meet  human  factors  requirements,  response  to  aircrew  keyset  input  must  oc¬ 
cur  within  200  ms.  for  most  inputs.  Each  response  takes  1  ms.  to  complete  with  a 
maximum  of  1 0  keyset  inputs  per  second. 

For  the  HOTAS,  the  target  designation  response  must  occur  within  40  ms.  and 
requires  1  ms.  to  complete.  The  response  to  pushing  the  bomb  button  must  occur 
within  40  ms.  of  initiation  and  requires  1  ms.  to  complete.  This  is  in  addition  to  the 
weapon  release  processing  described  in  Section  3.8. 
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Inputs 

DP.Keyset_RWR_Program_Message 

DP.Keyset_Weapon_Program_Message 

DP.Keyset_Target_Designation_Message 

DP.Keyset_Delivery_Mode_Toggle_Message 

Outputs 

Keyset. Waypoint_Table  (latitude,  longitude,  altitude) 

Keyset.  WaypointjDff  set  (range,  bearing) 

Keyset.Waypoint_Steering_Se!ected 

Keyset.Quantity_Select_Request 

Keyset.lnterval_Select_Request 

Keyset.AUTO_CCIP_Toggle 

Keyset.  RWR_Frequency_Table 

Keyset.  R  WR_Search_Sector_T  abl  e 


3.15.  RWR  Control 

The  Radar  Warning  Receiver  (RWR)  consists  of  numerous  radar  receptors  scattered  about 
the  aircraft  connected  to  a  special-purpose  computer  which  analyzes  any  radar  receptions 
to  determine  the  frequency  and  the  estimated  bearing.  The  RWR  reports  contacts  only  for 
those  frequencies  and  in  those  sectors  requested  by  the  aircrew  via  the  MCC.  This  function 
accepts  aircrew  inputs  and  “programs”  the  RWR. 

Timing 

Programming  of  the  RWR  must  be  completed  within  400  ms.  of  completion  of 
aircrew  inputs.  During  RWR  programming,  response  to  aircrew  key  pushes  must 
occur  within  200  ms.  to  meet  human  factors  requirements.  Each  response  to  a 
button  depression  requires  1  ms.  to  complete  with  20  button  depressions  required 
to  program  the  RWR.  Two  additional  milliseconds  are  required  to  format  the  mes¬ 
sages  to  be  sent  to  the  RWR. 

Inputs 

Keyset.RWR_Frequency_Table 
Keyset.  RWR_Search_S  ector_T  abl  e 

Outputs 

RWR.Threat_Radar_Frequency_Message 

RWR.Threat_Search_Sector_Message 
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3.16.  RWR  Threat  Response 

When  the  RWR  detects  radar  energy  in  one  of  the  frequency  ranges  and  within  one  of  the 
sectors  selected  by  the  aircrew,  it  notifies  the  MCC,  which  must  generate  a  warning  to  the 
aircrew  and  also  update  the  MPD  tactical  display. 

Timing 

The  MCC  must  poll  the  RWR  every  200  ms.  to  determine  if  any  threats  have  been 
detected  at  the  specified  radar  frequency  bands  and  within  the  designated  search 
sectors.  Two  ms.  are  required  to  poll  the  RWR.  If  any  threats  have  been  de¬ 
tected,  the  selected  threat  response  must  occur  within  100  ms.  of  initiation  and 
requires  3  ms.  to  complete.  These  timing  requirements  are  necessary  to  allow  for 
human  response  to  the  possible  threat,  to  ensure  threats  are  not  lost,  and  to  ac¬ 
count  for  processing  time  for  an  appropriate  response  consistent  with  the  threat. 

Inputs 

RWR. Threat_Table  (bearing,  frequency) 

Outputs 

SMS. Stores_Select 
SMS.Stores_Release 
MPD.Threat_Warning 
H  U  D .  Th  reat_Warni  ng 


3.17.  Built-In  Test 

The  built-in  test  (BIT)  function  periodically  queries  each  aircraft  device  and  analyzes  re¬ 
sponses  to  determine  if  a  failure  has  occurred.  Results  are  displayed  as  part  of  the  MPD 
status  display.  If  BIT  detects  equipment  failure  while  the  MPD  status  display  is  not  selected, 
a  warning  legend  is  flashed  on  both  the  HUD  and  the  MPD  for  2  seconds. 

When  the  MPD  status  display  is  selected,  the  aircrew  may  request  additional  tests  for  a 
particular  device.  Results  from  this  additional  testing,  called  initiated  BIT,  are  displayed  on 
the  MPD  status  display. 

Timing 

BIT  is  performed  every  second  and  takes  5  ms.  to  complete.  BIT  results  must  be 
displayed  within  400  ms.  of  initiation.  The  flashing  display  warning  of  device 
failures  or  degradations  must  occur  within  200  ms.  of  detection  and  is  assumed  to 
take  no  additional  processing  time.  These  timing  requirements  are  necessary  to 
meet  human  response  requirements. 

Initiated  BIT  normally  takes  less  than  10  ms.  per  request,  including  display  proc¬ 
essing.  The  results  must  be  displayed  within  800  ms.  of  initiation. 
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Inputs 

Equipment  status  message 

Outputs 

MCC.Status 

ADC.Status 

I  NS. Status 

SMS.Status 

Radar.Status 

RWR.Status 

RALT.Status 

D  P .  M  P  D_Error_Adviso  ry_Messag  e 
DP.HUD_Error_Advisory_Message 
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Appendix  A:  Acronyms 


ADC 

air  data  computer 

AG 

air-to-ground 

AUTO 

automatic  delivery  mode 

BIT 

built-in-test 

CCIP 

continuously-computed  impact  point 

CPU 

central  processor  unit 

DP 

display  processor(s) 

HOTAS 

hands-on  throttle  and  stick 

HUD 

head-up  display 

INS 

inertial  navigation  system 

IOC 

input/output  completion  interrupt 

IOP 

input/output  processor 

Keyset 

aircrew’s  MCC  control  switches 

LOS 

line-of-sight 

MCC 

mission  control  computer(s) 

MPD 

multi-purpose  display 

RALT 

radar  altimeter 

RWR 

radar  warning  receiver 

SMS 

stores  management  system 

TDC 

target  designator  controller 
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Appendix  B:  Functional  and  Timing  Summary 

The  following  table  summarizes  the  functions  and  timing  information  provided  in  the  specifi¬ 
cation.  Utilizations  in  this  table  are  rounded  up  to  the  nearest  thousandths  to  guard  against 
underestimation  of  the  utilization  implied  for  a  1  MIPS  processor.  The  total  workload  for  all 
functions  exceeds  100%  for  several  reasons: 

1 .  It  is  possible  for  the  aircrew  to  overload  the  MCC  by  requesting  too  much 
processing;  when  that  occurs,  less  important  workload  must  be  shed  to 
guarantee  deadlines  for  more  important  workload.  Table  B-1  indicates  the  rel¬ 
ative  importance  of  different  functions. 

2.  Normally  only  a  few  of  the  many  possible  aperiodic  tasks  are  performed  at  any 
one  time.  For  example,  of  the  MPD  display  functions  (HUD,  tactical,  status, 
and  stores),  at  most  one  can  be  selected  at  any  given  time.  Moreover,  de¬ 
pending  on  mission  phase,  some  functions  are  more  likely  to  be  performed 
than  others.  Table  B-1  indicates  the  likelihood  that  each  function  will  be  per¬ 
formed  during  the  weapon  delivery  phase  of  the  mission.  In  calculating  the 
total  worst-case  workload,  we  have  included  only  those  functions  charac¬ 
terized  as  “certain”,  “likely”,  or  “possible”. 

The  following  scenario  specifies  indirectly  which  functions  need  to  be  performed  during  the 
weapon  delivery  phase  of  a  mission.  * 

A  fighter/attack  aircraft  is  making  an  air-to-ground  attack  on  a  heavily  defended 
ground  target  with  ballistic  weapons,  using  a  video  TV  sensor  for  targeting.  All 
keyset  entries  needed  to  select  the  weapon,  the  weapon  delivery  mode,  the  tar¬ 
get,  and  the  targeting  sensor  have  been  made.  No  more  keyset  entries  are  ex¬ 
pected.  The  only  aircrew  input  is  via  the  HOTAS  bomb  button  and  the  HOTAS 
target  designator  control  (TDC). 

The  TV  sensor  is  locked  on  and  tracking  the  target.  As  the  aircraft  nears  the  tar¬ 
get,  the  aircrew  will  “sweeten”  the  target  by  adjusting  the  TDC  symbol  on  the 
HUD.  This  will  probably  happen  three  times  to  get  the  TDC  symbol  exactly  on 
target.  (“Sweetening”  will  precede  weapon  release.) 

Since  the  target  is  heavily  defended,  the  aircrew  initiates  the  radar  warning  sys¬ 
tem  and  selects  AUTO  delivery  mode.  The  aircrew  will  follow  the  steering  cues  on 
the  HUD  to  the  weapon  release  point  computed  by  the  MCC.  Weapon  release  is 
triggered  by  the  MCC,  but  only  if  the  HOTAS  bomb  button  is  depressed.  The 
“bomb  button"  task  then  runs,  followed  by  a  train  of  six  "weapon  release”  actions 
(one  for  each  of  six  bombs).  The  minimum  release  interval  is  assumed  to  be  10 
ms.  However,  the  weapon  release  calculation  must  complete  within  5  ms.  after 
each  initiation  to  ensure  accurate  delivery  (a  “jitter”  requirement). 

immediately  after  weapon  release,  the  target  defenses  fire  surface-to-air  missiles 
at  the  aircraft,  triggering  the  threat  display  and  response. 

Given  this  scenario,  we  can  reasonably  assume  that  the  following  functions  have  already 
been  performed  before  the  weapon  delivery  phase:  target  designation  and  confirmation, 
weapon  selection,  initialization  of  trajectory  computation,  MPD  status  display,  requests  for 
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additional  built-in  test  for  questionable  components,  all  necessary  keyset  processing,  and 
RWR  programming.  The  only  aperiodics  expected  to  occur  during  weapon  delivery  are: 
target  sweetening,  weapon  release  (six  times),  and  bomb  button.  Others  are  possible,  but 
not  expected:  AUTO/CCIP  toggle,  trajectory  reinitiation,  and  BIT  failure  warning. 

The  total  worst-case  workload  during  the  weapon  delivery  phase  is  summarized  below, 
based  on  the  information  in  Table  B-1. 

Periodic  Aperiodic  Total 
critical  0.541  0.110  0.651 

essential  0.280  0.015  0.295 

background  0.005 _ 0.005 

Total  0.826  0.125  0.951 
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Sec.  Function 

CPU 

Period  Deadline 

Importance 

Likelihood 

Util. 

Class1 

Navigation 

3. 1  Aircraft  flight  data 

8  ms. 

55  ms. 

critical 

certain 

.1462 

CP 

3.2  Steering 

6 

80 

critical 

certain 

.075 

CP 

Radar  Control 

3.3  Radar  search  or 

2 

80 

critical 

unlikely 

Radar  tracking 

2 

40 

critical 

likely 

.050 

CP 

Initiate  tracking 

2 

200 

essential 

unlikely 

Targeting 

3.4  Designate  target 

1 

40 

critical 

unlikely 

Confirm  designation 

1 

200 

critical 

unlikely 

3.5  Target  tracking 

4 

40 

critical 

certain 

.100 

CP 

Target  sweetening 

2 

40 

critical 

likely 

.0503 

CA 

Weapon  control 

3.6  Input  for  weapon  selection 

1 

200 

essential 

unlikely 

Weapon  selection  processing 

2 

400 

essential 

unlikely 

.0053 

AUTO/CCIP  toggle 

1 

200 

critical 

possible 

CA 

3.7  Weapon  trajectory 

7 

100 

critical 

certain 

.070 

CP 

Reinitiate  trajectory 

6 

400 

essential 

possible 

.01 52 

cA 

3.8  Weapon  release 

1 

10 

54 

critical 

certain 

.100s 

CP 

Controls  and  Displays 

3.9  HUD  display 

6 

52 

essential 

certain 

.116 

EP 

(assuming  AUTO-delivery) 

3.10  MPD  HUD  display 

6 

52 

essential 

unlikely 

3.11  MPD  tactical  display 

8 

52 

essential 

likely 

.154 

EP 

MPD  button  response 

1 

200 

background 

unlikely 

Change  display  mode 

1 

200 

background 

unlikely 

3. 1 2  MPD  stores  display 

(see  3.6,  above) 

3.13  MPD  status  display 

2 

1000 

background 

unlikely 

BIT  failure  warning 

(see  3.17,  below) 

3.14  Keyset  response 

1 

100 

200 

background 

unlikely 

HOTAS  designation 

1 

40 

critical 

unlikely 

.0253 

HOTAS  bomb  button 

1 

40 

critical 

certain 

CA 

3.16  Threat  response  display 

(see  3.16,  below) 

RWR  Control 

3.15  RWR  program  input 

1 

100 

200 

background 

unlikely 

RWR  programming 

2 

400 

background 

unlikely 

Threat  response 

3.16  Poll  RWR 

2 

200 

essential 

likely 

.010 

EP 

Threat  response  display 

3 

100 

critical 

likely 

.0303 

CA 

Built-in  Test 

3.17  Periodic  BIT 

5 

1000 

400 

background 

certain 

.005s 

BIT  failure  warning 

200 

essential 

possible 

Initiated  BIT 

10 

800 

background 

unlikely 

’Note:  cp  indicates  a  critical  periodic  task;  CA,  critical  aperiodic;  EP,  essential  periodic;  and  ea,  essential 
aperiodic. 

2Note:  rounding  is  always  to  the  next  higher  number  since  we  must  not  underestimate  utilization. 

3Note:  Aperiodic  workload  during  the  weapon  delivery  phase. 

4Note:  Weapon  release  executes,  when  active,  at  a  1 0  ms.  maximum  rate  with  a  jitter  requirement  to  complete 
within  5  ms.  of  initiation  of  each  period. 

sNote:  Utilization  is  based  on  the  period,  not  on  the  deadline. 

Table  B-1 :  Summary  of  Timing  Data 
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